IBIS Macromodel Task Group

Meeting date: 26 April 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):           Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Arpad to create a draft 23 of BIRD213.1 with the changes discussed during the
  meeting.
  - Done.
    
- Randy to add the Ignore_Bits -> Ignore_Symbols issue to the IBIS 7.1 Known
  Issues Document.
  - Done.  Randy reported that the issue was discussed at the Open Forum meeting
    on April 22nd.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 19th
meeting.  Ambrish moved to approve the minutes.  Michael seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD219.1 draft 1 AMI Parameter Root Name Clarifications:
Michael shared the draft.  He noted that the most important point was that this
version introduced a new requirement, for AMI_Version 7.2 and beyond, that the
model "shall report mismatches as part of its message string..."  Based upon
results from the informal poll conducted on the ATM list the previous week,
this version adopted the strictest of the 3 choices of language that had been
proposed for defining the model's obligation to check the root name in the
AMI_parameters_in string.

Ambrish asked if this was really to be a requirement for all models after 7.1.
Michael said it was, per the language most respondents had selected during the
informal poll.  Ambrish asked how we would enforce this requirement.  Michael
said we could ask the parser to deliberately pass in a mismatched root name and
confirm that the model reports the mismatch.  Arpad noted that since the model's
only requirement is to "report mismatches" via the message string returned in
msg, checking wouldn't be trivial since we haven't defined the format and
content of the message used to report a mismatch.

Ambrish objected to the idea of requiring all models to check for and report
such a mismatch.  He said the model may not care, and it shouldn't have to check
or report anything if it doesn't care.  He said the important point is that if
the model does check, then if it finds a mismatch it should be obligated to
return a message indicating what it expects.  He said that in his experience the
model may fail to behave properly based on the input root name, and then the
user has no idea what the problem is if the model doesn't report on it.  Michael
asked why we have the requirement [that at least the root name of the parameter
tree be passed in] in IBIS 7.1 at all if models may not care?  Ambrish agreed
that the requirement in 7.1 might be the real problem.

Arpad suggested we step back and ask why we are doing this.  He asked, "What if
the user combines the wrong .ami file with the .dll?"  The .dll's functions
might have defaults and proceed even if the AMI_parameters_in string didn't
make sense.  Then the user might not know their simulation results could be
garbage.  Ambrish said all we can do is suggest, "If your model is checking the
root name, then you should return a message if you don't like what you find."
He said if the model isn't checking the root name, then who cares?

Randy said that as an AMI model creator, his expectation was that most people
creating models were in fact relying on one of several tools to generate their
AMI models.  His expectation was that any such tools would be responsible for
creating models that comply with this proposed requirement.  Arpad agreed that
asking the model to check the root name in the input string seemed a trivial
task.  Even if someone were writing their model from scratch, checking a
string's value is trivial compared to other things AMI models have to do.

No one joined Ambrish in expressing objection to the requirement, but the group
agreed to change the wording for the model's obligation to the least stringent
of the original three choices in the poll.  The model is "strongly recommended"
to check and report mismatches.  Arpad said that with the new relaxed language,
the models could now continue current behavior and not do anything.  We haven't
solved any problem.  Arpad noted that we no longer needed the explicit mention
of version 7.2 in this section, since we aren't adding a new requirement on the
models.

With respect to the string returned by the model via AMI_parameters_out, the
group agreed to keep the new language stating that the EDA tool must compare the
returned root name with that of the .ami file and report mismatches.  Bob asked
if the parser would have any obligation based on this language.  Michael said
the parser could serve as a proxy EDA tool and check the root name returned by
the model [when and if the parser functionality is expanded so that it actually
calls executable model functions].

- Curtis: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

AR: Michael to create draft 2 of BIRD219.1 containing today's changes and send
    it to the ATM list.
    
-------------
Next meeting: 03 May 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
